Generally, graphical analysis, simulation, and execution methods are used in modeling, design, analysis, and synthesis of engineered systems. These methods provide a visual representation of a model, such as a block diagram. The visual representation provides a convenient interpretation of model components and structure. The visual representation also provides a quick intuitive notion of system behavior. The components of a block diagram also can capture the mathematical representation of the actual system being modeled.
Various classes of block diagrams describe computations that can be performed on application specific or general purpose computational hardware, such as a computer, microcontroller, field-programming gate array (FPGA), and custom hardware. Classes of such block diagrams include time-based block diagrams such as those found within Simulink® from the MathWorks, Inc. of Natick, Mass., state-based and flow diagrams such as those found within Stateflow® from the MathWorks, Inc. of Natick Mass., entity flow network diagrams such as those found within SimEvents from the MathWorks, Inc. of Natick, Mass., and data-flow diagrams. A common characteristic among these various forms of block diagrams is that they define semantics on how to execute the diagram.
Block diagram modeling has spawned a variety of software products that cater to various aspects of dynamic system analysis and design. Such products allow users to perform various types of tasks including constructing system models through a user-interface that allows drafting block diagram models, allowing augmentation of a pre-defined set of blocks with users' custom-built blocks, the use of the block diagram model to compute and trace the temporal evolution of the dynamic system's outputs (“executing” the block diagram), and automatically producing either deployable software systems or descriptions of hardware systems that mimic the behavior of either the entire model or portions of it.
Currently in Simulink®, each block is responsible for validating entities within the block, hence each block needs to maintain its own entity checking code. As a result, for custom-built blocks, such as S-Function blocks, a user needs to write an entity checking code for each of the custom-built blocks. Although this provides the user with the flexibility of how one wants to validate block entities, it is sometimes cumbersome and error prone due to unnecessary duplicate efforts or insufficient tests.
Additionally, each block is responsible for inferring block entity attributes, hence each block needs to maintain its own entity inference code. As a result, for custom-built blocks, such as S-Function blocks, a user needs to write an entity inference code for each of the custom-built blocks. Although this provides the user with the flexibility of how one wants to infer block entity attributes, it is sometimes cumbersome and error prone due to unnecessary duplicate efforts or insufficient tests.